Domain-Driven Design Quickly 日本語版
https://gyazo.com/f725a42402cea31a8739582b4e489d6e
本書の概要
ドメイン駆動設計の考え方が世の中の主流になるようにすることを目的としているらしい 内容メモ
イントロダクション
1 章 : ドメイン駆動設計とは何か
ソフトウェアを開発する目的は、実世界の作業の自動化だったりビジネス上の問題解決だったりする
つまり、ソフトウェアは具体的なドメインのためのソフトウェア ソフトウェアは特定のドメインから生まれ、そのドメインと深くかかわっている
ドメインの知識を持っているのは、その業務にあたっている人たち (例えば銀行業務であれば銀行員)
ドメインに円滑に適合するソフトウェアを開発するには : ドメインの反映としてのソフトウェアを作る (ドメインをモデル化する)
例えば、銀行業務の知識がなくても、ドメインのモデルのコードを読むことで多くのことが理解できるように
ドメインモデルとは、何か特定の図などで表現されるものではなく、概念 (図や文書、コードなどでその概念を表現)
一人で作業するわけではないので、モデルを他人に伝えられる状態にすることが重要
ドメインの専門家とソフトウェアの専門家が一緒にドメインモデルを構築する例の紹介 (航空監視システムの例)
2 章 : ユビキタス言語
ドメインの専門家とソフトウェアの専門家のコミュニケーションの壁 : 言語の違い
ソフトウェアの専門家はソフトウェア開発の用語や思考で会話するし、ドメインの専門家は領域の専門用語を使う
あらゆるコミュニケーションにこの言語を使う : ユビキタス言語と呼ばれる ユビキタス言語をどう表現するか？
図を描いたり、UML で表現したり、文章を書いたりコードで表現したり、いろいろある 3 章 : モデル駆動設計
モデルからコードに至るまでの手法をどうするか？
分析モデルという設計手法 (?) があるが、これではモデルとコードが乖離しがち コード設計者とは別の人がモデルを作るので、ソフトウェアに落とし込みにくいものになりやすい
より良い方法は、ドメインモデリングと設計を密接にすること
モデルを作成するときにはソフトウェアとその設計を考慮する
開発者もモデリングに参加する
https://gyazo.com/1085dcf96a8e4a4d49089c83fa31b400
4 章 : リファクタリングのためのさらに深い考察
コードを対象としたリファクタリングはパターン化できるし、組織化して体系化することができる 一方で、モデルに対する、さらに深い洞察を得るためのリファクタリングはそういうわけにはいかない
リファクタリングをするのは、ドメインをより深く理解し、その理解に応じてモデルやコードを洗練させるためでもある
5 章 : モデルの完全性を維持する
複数チームが協働するような巨大プロジェクトの話
モデルの完全性を維持するための方法
https://gyazo.com/9bbad57be24589eb7c67068a16e2c470
継続的な統合
異なるコンテキスト同士の相互作用
インタビューがある